阿里巴巴服务网格技术三位一体战略背后的思考与实践

作者：宗泉、宇曾

01

阿里巴巴三位一体战略

Cloud Native

阿里云内部很早就提出了开源、自研、商业化三位一体战略，先谈谈我对它的理解。

多年的软件开发经验告诉我们，开发出一款出色的软件有一些关键要素：

• 沟通
• 反馈

• 实践

在软件开发过程中我们不能闭门造车，不能随意“创造”业务场景需求。业务场景和产品功能需要提炼，开源给我们提供了一个共同创新的平台，基于这个平台，大家可以共同定义一些规范和标准。不同的厂商遵循相应的标准，客户就没有被锁定的风险，可以不停地迁移，总是能找到最好的厂商，将自己的业务放上去，用最简单、最便捷、最经济的方式来运营自己的业务。

很多客户在选择阿里云服务网格的时候，有一条比较重要的评判指标：是否和社区 Istio 兼容。因为客户担心被锁定，强依赖于阿里云；

然后说到自研，也许有同学会问到，开源与自研是否互相矛盾，答案是否定的。

因为，我们这里提到的自研，其实是基于开源的自研，并非摒弃开源的版本，重新造个新的轮子。自研是指我们要对开源产品有足够深度的理解：

• 要掌握所有源代码；
• 拥有修改每一行代码的能力

• 当然，自研还有意味着可能有自身业务特定独有的需求场景，一些没办法标准化的场景。

基于自研，对开源产品的深度把控和理解，我们将有通用客户场景需求的功能搬到云上，封装成云产品，让云上客户可以开箱即用去使用，这是商业化的初心。

回到阿里集团内部，开源、自研、商业其实是一个技术飞轮。

对于阿里的技术同学来说，每年的 双11 都是一场“盛宴”。为了让顾客有顺滑的购物体验，给商户提供更多样化的让利活动，阿里电商平台对于效率、可靠性、规模性的要求在 双11 的驱动下成倍提高，激发着技术人的潜力。作为基础技术核心之一，阿里巴巴中间件也会在每年 双11 迎来一次技术的全面演进和升级。

阿里在开源社区中推出了 Dubbo、RocketMQ、Nacos、Seata 等多个为人熟知的开源项目，鼓励广大开发者共建中间件生态体系，也包括了 ServiceMesh 相关技术。

02

拥抱服务网格开源技术

Cloud Native

阿里云内部很早就开始调研并实践 ServiceMesh 技术 。2018 年，Istio 正式发布 1.0 版本，进入大众视野。在这更早时期，阿里巴巴内部已经开始参与相关生态开源产品的贡献。

阿里云在微服务生态领域，也有一些开源的服务化框架，比如 Dubbo 、Spring Cloud Alibaba，可以说微服务领域，因为电商这层试验大平台，阿里云在这方面是妥妥滴“技术专家”，我们会进行横向功能对比，对比 Sidecar 模式和原有模式的优缺点；在这过程中，我们也积极参与 Istio 微服务相关生态项目的开源贡献；例如 Envoy、 Dubbo Filter 、RocketMQ Filter 、Nacos Mcp 功能、Spring Cloud Alibaba、Sentinel 等。

目前流行着各种各样的服务框架，如何基于不同的框架开发的可互通的业务？服务框架就像铁路的铁轨一样，是互通的基础，只有解决了服务框架的互通，才有可能完成更高层的业务互通，所以用相同的标准统一，合二为一并共建新一代的服务框架是必然趋势。

Dubbo 和 HSF 都是阿里巴巴内部在使用的微服务 RPC 框架。这些框架在阿里业务不断迭代开发的过程提供了坚实的底层微服务能力支持，保障了一个又一个 双11 大促。

伴随着云原生的浪潮，以及整体资源成本优化、DevOps 等大背景下，原有微服务框架 Dubbo 、HSF 的一些缺点也在慢慢暴露出来，比如多语言的支持，配置和代码逻辑分离等，SDK 版本升级需要推动业务方，收购的业务采用不同框架互通的问题等。

阿里集团内部部分业务开始尝试使用服务网格技术来改造底层微服务框架，Dubbo 框架在 Mesh 化的过程中，阿里云服务网格团队贡献了 Envoy Dubbo Filter，就是为了实现原有 Dubbo 业务的 Mesh 化，以获得服务网格带来的新的增量价值。

另一方面，Dubbo 社区本身也在朝着云原生领域往前迭代。Dubbo 从 Dubbo2.7.8 版本开始探讨 Dubbo 的云原生演进方案，为了更好地适配云原生场景 （基础设施的变化 Kubernetes 已成为资源调度编排的事实标准），Dubbo 团队目前在将 Dubbo 2.0 向 Dubbo 3.0 做技术演进，并提出了 Proxyless Mesh 的设计。

随着业务逐渐上云，由于上云路径的多样以及从现有架构迁移至云原生架构的过渡态存在，部署应用的设施灵活异变，云上的微服务也呈现出多元化的趋势。跨语言、跨厂商、跨环境的调用必然会催生基于开放标准的统一协议和框架，以满足互通需求，这些场景，正式服务网格擅长的领域，给了服务网格很好的发挥空间；

目前，Dubbo 3.0 社区版本已发布，核心变化有：

• 应用级服务发现
• Dubbo 2.0 协议演进为 基于 gPRC 的 Triple 协议
• 无 Sidecar 的 ProxylessMesh

Mesh 化不是一蹴而就，对于原有的存量业务类似业务上云，存在一个中间过渡阶段，传统微服务框架，例如：Dubbo 、Spring Cloud 等存量业务采用 Nacos、Eureka 、Zookeeper 服务注册中心，我们需要对它进行兼容适配；基于 Istio 控制面开放的 Mcp Over XDS 协议，优先在 Nacos 实现了该协议支持，让 Istiod 可以直接对接 Nacos 注册中心。

开源产品在大规模生产环境往往不能直接使用，需要做一些适配和调优，以及一些产品化能力的封装；例如：Intel 的 mTLS 加速方案。

Intel 提交了 Envoy 侧 Upstream 的实现，但 Istiod 还未支持。作为云产品，我们希望提供给客户开箱即用的能力，服务网格 ASM 基于 Intel 开源的 mTLS 加速方案，实现了控制面 Istiod 的扩展支持，而且因为该 mTLS 加速方案依赖底层资源的实际 CPU 机型（icelake)，ASM 针对用户业务实际部署做了自适应的加速功能的开启和关闭，multiBuffer 加速功能在开启状态下，采用阿里云 g7 代 ecs 作为 node 节点，QPS 有接近 80% 的提升。

提到服务网格，经常被提起的一个话题：“它和 Dapr 的区别是什么？”

Dapr 使用 Sidecar 架构，与应用程序一起作为单独的进程运行，包括服务调用、网络安全和分布式跟踪等功能。这经常会引发一个问题：Dapr 与 Istio 等服务网格解决方案相比如何？

虽然 Dapr 和服务网格确实存在一些重叠功能，但与专注于网络问题的服务网格不同，Dapr 专注于提供构建基块，使开发人员更容易将应用程序构建为微服务。Dapr 以开发人员为中心，而服务网格以基础设施为中心。此外，Dapr 不提供路由或流量分配等关于流量控制的功能。

当然, 两者可以部署在一起，此时，Dapr 和服务网格的 Sidecar 都在应用环境中运行。

03

服务网格在阿里巴巴的落地和实践

Cloud Native

前面可以看到阿里针对微服务生态，开源了一些产品，这些产品其实在最开始都是因为有内部业务场景，基于这些内部业务场景的孵化和大规模业务检验，内部觉得外部客户也有类似需求，所以才把这些内部实现全部开源。

对应 Istio  Mesh 同样也是，集团内部业务在很早就开始了 Mesh 的业务探索，我们具体来看：

从整体架构图可以看到，阿里集团内部提供了一套控制台供 Mesh 用户操作，控制台以应用为视角，集成 CICD、权限管理、安全生产、SRE 运维系统等其他平台，提供应用接入 Mesh 化后的统一 Portal ，让用户可以基于 DevOps 的理念，实现对应用的全生命周期管理，并通过 Mesh 方式提供应用服务治理、全链路灰度以及安全生产等能力，达到应用 Owner 可以自助和自愈运维的效果。

其中，Mesh 核心能力支持对 Dubbo 、MetaQ(RocketMQ) 、LWP 等 RPC 协议的支持，扩展实现了全链路染色、路由策略、插件市场等 Mesh 能力。

同时，阿里集团内部也支持通过 OpenAPI 、Kubernetes API 方式提供给第三方系统集成的能力。

在社区 Istio 架构的基础上，阿里集团内部和内部中间件（Diamond、ConfigServer ） 做了深度集成，兼容保留业务的原始使用方式，让业务无缝接入到 Mesh ，这也是我们考虑到部分 Mesh 业务有需要使用 Nacos ，在 ASM 产品层面支持 Nacos 等多注册中心的场景；

同时抽象出运维平面，可以通过 UI 控制台的方式实现服务流量治理规则（virtualservice、destinationrule 等) 的配置，同时通过和 OpenKrusise 的集成，实现 pod 粒度的 Sidecar 的开启、关闭以及热升级等功能，通过对集团内部 Prometheus 和 Grafana 以及告警 ARMS 的集成，实现微服务的可观察和可监控。

1

 阿里集团服务网格的演进路径

阿里集团服务网格演进分为三个阶段：无侵入部分规模化、无侵入全面规模化、云原生终态，目前集群业务 Mesh 化处于第二阶段。

第一阶段：存量业务 Mesh 化存在一个过渡阶段，而且需要保障这个过渡阶段相对无侵入，让业务开发者无感知；这是为什么我们需要采用无侵入方案的背景和前提；并且需要采用 Mesh 覆盖已有的微服务治理的能力，同时提供 Mesh 的增量价值；

第二阶段：全面规模化，同时解决规模化带来的资源开销和性能问题，通过 Sidecarcrd 实现服务配置懒加载，达到配置隔离的问题，通过对 Metrics 的优化裁剪，降低 Sidecar 内存开销，同时通过优化 Dubbo/HSFFilter 实现惰性编解码，提高数据面处理性能降低延迟。

随着内部业务 Dubbo 2.0/HSF 演进到 Dubbo 3.0 ，最终演进到云原生终态方案。

第三阶段：云原生终态，随着基础设施向 Kubernetes 演进，在云原生场景下，服务发现、服务治理能力下沉，通过 Mesh 可以解耦业务逻辑和服务治理，实现配置和代码逻辑分离，从而更好地 DevOps 化，并享受 Mesh 带来的丰富的可扩展流量调度能力和可观察性。

Dubbo/HSF RPC 支持多种序列化方式，而 Mesh 针对一些序列化并不能做到很友好的支持，比如 Java 序列化。

因此，业务在 Mesh 化第一阶段，针对 Java 序列化，Sidecar 不做编解码，采用 Passthrough 流量透传的方式；针对 Hessian2 序列化，Mesh 实现了完整的编解码支持，并基于性能考虑实现了惰性编解码。基于此，我们可以实现对这类流量实现流量打标（染色）并通过扩展 VirtualService 的方式，实现标签路由和 Fallback 的能力。还可以实现一些特定的业务场景，如金丝雀发布、全链路灰度等场景；

内部业务 MeshSDK 这层会逐步升级到 Dubbo3.0 SDK，在开启 Mesh 的场景下，Dubbo3.0 SDK 仅提供 RPC 等能力，对应 ThinSDK 模式，Mesh 化后，Sidecar 的协议支持友好度更好、资源开销成本有一定的降低；当 Sidecar 故障时，可以快读切回 FatSDK 模式，业务无感知；

对于集群内部业务，流量调度存在一些较为复杂的场景，特别是一些规模较大的业务。比如多机房多区域部署， 同时在单个区域下还存在服务多版本、多环境的的路由等

这就涉及到不同维度的路由和后端 cluster 选择，这些维度可能有：

• 区域化路由
• 机房路由

• 单元化路由
• 环境路由

• 多版本路由

集团电商场景尤为典型，基于此，内部扩展 Istio 通过引入新的 CRD：RouteChain、 TrafficLable 以及对 VirtualService 的扩展，实现了对流量打标和按标路由的能力。

商业化产品阿里云服务网格 ASM 也将这些能力进行了不同程度的透出，可以基于此实现比如金丝雀发布、A/B 测试、全链路灰度等场景。

04 云产品：阿里云服务网格 ASM

Cloud Native

前面我们介绍了阿里巴巴服务网格在开源和大规模落地方面的实践，接下来分享下在云原生三位一体中关于云产品方面的设计。阿里云通过总结业务场景落地经验，持续驱动技术发展，沉淀一系列服务网格核心技术。

在大规模落地方面：比如按需动态推送规则配置，大规模业务无损下 Sidecar 热升级，支持最全面的异构计算基础设施，支持多注册中心与平台。

在流量治理方面：提供了精细化的流量控制，按需对流量协议、端口动态拦截，零配置实现请求标签路由以及流量染色，支持多种协议的精细化治理。

在可观测能力方面：提供了日志、监控与跟踪融合的一体化智能运维，同时基于 eBPF 增强可观测性，实现无侵入实现全链路可观测，辅助业务快速排障。

在安全能力方面：支持 Spiffe/Spire、实现零信任网络、增强认证鉴权机制, 支持渐进式逐步实现 mTLS。

在性能优化方面：通过 eBPF 技术进行网络加速，实现软硬一体的性能优化。

阿里云服务网格 ASM 是业界首个兼容 Istio 的托管式服务网格平台，支持完整的服务网格产品能力：精细化的应用流量管理、端到端的可观测能力、安全和高可用；支持多语言多环境、多种微服务框架、多协议互联互通等复杂场景。服务网格 ASM 技术架构已经升全面升级 V2.0， 托管了控制面核心组件，保证了标准版和专业版的架构统一，平滑支持社区各个版本的升级。同时 ASM 在和社区标准统一的基础上进行各种能力增强。主要包括流量管理和协议增强，支持多种零信任安全能力，支持对接 Nacos、Consul 等多种注册中心。除此之外通过网格诊断能力快速分析网格的健康状况，配合控制面告警快速响应。

服务网格 ASM 和各种云服务能力充分融合，包括链路追踪、Prometheus 监控、日志服务等可观测能力。集成 AHAS 支持服务限流、集群限流和自适应限流，结合微服务引擎 MSE 支持服务治理，并且能够给跨 VPC 多集群提供一致的治理体验。在自定义扩展方面支持 OPA 安全引擎，webAssembly 等自定义扩展能力。

用户可以通过 ASM 控制台、OpenAPI、声明式云原生 API、数据面和控制面 Kubeconfig 使用服务网格技术。通过服务网格 ASM 在控制面和管控面的打磨，可以为运行在异构计算基础设施上的服务提供统一的网格化治理能力（Anywhere Service Mesh），从入口网关到数据面 Sidecar 注入，支持容器服务 ACK、Serverless kubernetes、边缘集群和外部注册 Kubernetes 集群，以及 ECS 虚拟机等多种基础设施。

1

 服务网格 ASM 的功能设计

基于 ASM 的流量打标和标签路由实现全链路灰度。微服务软件架构下，业务新功能上线前搭建完整的一套测试系统进行验证是相当费人费时的事，随着所拆分出微服务数量的不断增大其难度也愈大。基于“流量打标”和“按标路由” 能力是一个通用方案，可以较好地解决测试环境治理、线上全链路灰度发布等相关问题。并且基于服务网格技术可以做到与开发语言无关，该方案适应于不同的 7 层协议，当前服务网格 ASM 已经支持 HTTP/gRpc 和 Dubbo 协议。在 ASM 中引入了全新的 TrafficLabel CRD 用于定义 Sidecar 所需透传的流量标签从哪里获取，全链路流量控制进行逻辑隔离，对流量进行打标（染色）和按标路由，通过使用服务网格 ASM，无需每位技术研发人员部署一整套环境，实现多环境治理，大幅度降低研发成本。

服务网格 ASM 支持实现金丝雀发布。发布是整个功能更新到线上的最后一个环节，一些研发过程中累计的问题，在最后发布环节才会触发。同时发布本身也是一个复杂的过程，在发布过程中，往往容易出现一些错误操作或者遗漏关键操作。金丝雀发布配置灵活，策略自定义，可以按照流量或具体的内容进行灰度（比如不同账号，不同参数），出现问题不会影响全网用户。图中给应用打上环境标签， 通过 TrafficLable 对用户流量比如对 http-header: user-id % 100 == 20 打上 gray 标签，同时通过 VirtualService 下发标签流量路由规则，所以 userId 为 120 的用户流量会被路由到 gray 灰度环境，userId 为 121 的用户流量被路由到 normal 正常环境。服务网格 ASM 实现的金丝雀发布支持按流量百分比路由，按请求特征（如 http header, 方法参数等）路由，并且和服务网格入口网关完美集成，支持 HTTP/gRPC/Dubbo 协议 。

除了使用流量打标和标签路由得实现全链路灰度和金丝雀发布，服务网格 ASM 也支持和 KubeVela 结合实现渐进式发布。KubeVela 是一个开箱即用的、现代化的应用交付与管理平台，能够简化面向混合环境的应用交付过程；同时又足够灵活可以随时满足业务不断高速变化所带来的迭代压力。KubeVela 后的应用交付模型 Open Application Model（OAM）是一个从设计与实现上都高度可扩展的模型，具有完全以应用为中心、可编程式交付工作流、与基础设施无关的特点。阿里云服务网格 ASM 支持结合 KubeVela 进行复杂的金丝雀发布流程可以将 KubeVela 定义的相关配置转化为流量治理规则下发到数据面。

阿里云服务网格 ASM 实现了零信任安全能力。在微服务网络中使用 HTTP 通信的交互并不安全，一旦内部的某个服务被攻陷，攻击者能够以该机器为跳板来攻击内网。服务网格 ASM 能够减小云原生环境中的被攻击面积，并提供零信任应用网络所需的基础框架。通过 ASM 管理服务到服务的安全性，可以确保服务网格的端到端加密、服务级别身份认证和细粒度授权策略。

相比传统的在应用程序代码中构建安全机制，ASM 零信任安全体系具有以下优势：

• ASM Sidecar 代理的策略生命周期与应用程序保持独立，因此可以更轻松地管理这些 Sidecar 代理。
• ASM 支持动态配置策略，更新策略变得更加容易，更新立即生效而无需重新部署应用程序。

• ASM 提供了对附加到请求的终端用户凭据进行身份验证的能力，例如 JWT。
• ASM 的集中控制架构使企业的安全团队可以构建、管理和部署适用于整个企业的安全策略。

将身份验证和授权系统作为服务部署在网格中，如同网格中的其他服务一样，这些安全系统从网格中本身也可以得到安全保证，包括传输中的加密、身份识别、策略执行点、终端用户凭据的身份验证和授权等。策略控制面定义并管理多种类型的认证策略；网格控制面赋予网格中工作负载身份，并自动轮转证书；数据面的 Sidecar 代码执行策略。图中用户配置规则只允许交易服务发起调用订单服务，拒绝购物车服务调用订单服务。

由于服务网格 ASM 是控制平面托管，支持管控多个数据面集群，流量治理 CR 存在控制平面，支持用户通过控制平面的 KubeAPI 操作治理规则。在服务网格新版本中，为了：

1、支持用户在非托管模式下的操作习惯，能够在数据面 Kubernetes 集群中读写 Istio 资源 ；

2、支持 Helm 常用命令工具；

3、兼容其他开源软件在单集群 addon 模式下的 API 操作，阿里云服务网格 ASM 实现了支持数据面集群 Kube API 访问 Istio 资源。两者同时对外提供，用户可以根据实际场景按需使用。

ASM 兼容社区标准，提供了控制平面的平滑升级，那么数据面的升级可以升级两种方式：滚动升级和热升级能力，关于滚动升级能力需要设置升级 Strategy 为 RollingUpdate ，注入 Sidecar 的 Pod 在发布时，Envoy 镜像会自动升级到新版本。图中主要介绍第二种方式阿里云服务网格 ASM 结合 OpenKruise 项目实现的热升级功能，在升级数据平面时不会中断服务，使数据平面在应用无感知的情况下完成升级。应用发布和更新自动生成 SidecarSet 配置，更新 SidecarSet 配置完成数据面的升级，目前这项能力在新版本灰度中。

服务网格 ASM 配合阿里云应用高可用服务 AHAS 可以对部署在服务网格内的应用进行流量控制，目前已经支持单机限流，集群限流，自适应限流。同时服务网格 ASM 也原生支持 Istio 的全局限流和本地限流，全局限流使用全局 gRPC 服务为整个网格提供速率限制，本地限流用于限制每个服务实例的请求速率，本地限流可以与全局限流结合使用。

服务网格 ASM 也支持通过 MCP over XDS 协议对接微服务引擎 MSE 的注册中心，同步服务信息到网格。MSE 的 Nacos 原生支持 MCP 协议，用户只需要在创建或更新 ASM 实例时开启 Nacos 注册中心对接功能，实现注册中心的服务同步到服务网格，可以很方便地支持 Dubbo、Spring Cloud 服务的网格化，用户侧无需做任何业务代码修改。 

最后分享几个客户案例，客户如何使用服务网格 ASM 缩短服务网格技术落地周期、减轻异常排错成本，节省控制面资源成本。

1、东风日产随着业务的发展，早前打造的「十二生肖」（十二套完整的测试环境）已无法满足众多并发需求，甚至需要摇号分配环境。通过引入阿里云服务网格 ASM，构建了基于流量管理的「无限生肖」系统，满足了自动按需提供环境的诉求。基于 ASM 提供的免运维、易升级以及产品丰富支持能力，让产研团队集中享受 ServiceMesh 带来的价值。

2、职优你为了应对业务的全球化扩张与一体化运营，基于阿里云服务网格 ASM 和容器服务 ACK 将业务应用跨区域部署，通过服务按地域就近访问的策略，优化了客户访问体验，有效降低业务访问时延，提升业务响应速度。

3、商米科技引入阿里云服务网格 ASM，构建智能的数字化商业智能 POS 软硬件一体化系统解决方案，使用服务网格 ASM 解决 gRPC 服务负载均衡、链路追踪以及流量统一管理等核心问题。

本文分享了阿里巴巴服务网格技术三位一体战略背后的思考和实践，关于阿里云服务网格 ASM 的一些产品功能，包括最近发布的一些功能，例如 Istio 资源历史版本管理功能、支持数据面集群 Kubernetes API 访问 Istio 资源、支持跨地域故障转移和跨地域流量分布、支持控制平面日志采集和日志告警以及支持基于 KubeVela 实现渐进式发布等详细信息，以及更多关于流量管理，可观测，零信任安全，解决方案等产品功能，欢迎点击阅读原文访问阿里云服务网格 ASM 的产品文档。如果对服务网格 ASM 感兴趣，欢迎钉钉扫描下方二维码或搜索群号（30421250）加入服务网格ASM 用户交流群，一起探索服务网格技术。

点击阅读原文，查看更多服务网格 ASM 相关信息～

往期推荐